【レポート】GitHub Constellation Conference：GitHub Enterpriseで仕事をもっとおもしろくできる、GMOペパボの生産性向上への取り組み #githubconstellation
はじめに
本記事はGitHub Constellation Conferenceのセッション、「GitHub Enterpriseで仕事をもっとおもしろくできる、GMOペパボの生産性向上への取り組み」のレポートです。
レポート
スピーカーはGMOペパボ株式会社の柴田 博志さん。
自己紹介
@hsbt。GMOペパボの執行役員、CPO(Chief Productivity Officer)
会社全体の生産性を向上させる立ち位置。
ビジネスセッションではあるが、私自身がエンジニア。
Rubyの開発や付随する様々なライブラリを開発している。
GMOペパボについて
今はハンドメイド事業minneを展開。
古くはロリポップやムームードメインなど、インターネットに関わる様々な事業を行っている。
「インターネットで可能性をつなげる、ひろげる」がミッション。
インターネットを通じて個人の表現活動や想いをエンパワーしたい。
事業部制を取っており、各サービスを展開する事業部とバックオフィスを担当する事業部がある。
企業理念は「もっとおもしろくできる」
イベントやサービスを立ち上げる際には、もっとおもしろくできないか、を常に考える。
サービスローンチ直前までおもしろくすることを考え続けている。
GMOペパボのGitHub利用
2012年にあるサービスでGitHub.comの利用を開始。
2013年に様々なサービスで利用開始。
みんなが使い始めたが、内部統制上github.comにソースコードを置くことにハードルがあった。
内部統制対象になっているサービスでgithub.comを使うことが出来なかった。
サービスによって使いたいものを使えない、という状態を解決させるため、GitHub Enterpriseを導入。
GitHub/GHEのアカウント管理。
入社した社員全員にgithub.comのアカウントを作ってもらい、スクリプトで自社リポジトリに権限を付与。
2014年に社内の全てがgithub.comまたはGHEを利用。
サービス部門だけでなくバックオフィス部門も利用を開始。
サービスによってgithub.comとGHEを使い分けているため、頭の切り替えが難しい。
社長決定により、全社員でGHEを利用。
全社員がGHEを使うならgithub.comを使う意味がないため、github.comのリポジトリをGHEへ移行。
現在の利用ポリシー。
Organizationやリポジトリの作成は自由。
Public/Privateの分け方は厳密に規定。
外部委託の方もいるので運用が難しい。
アカウントの管理ポリシー。
悩みながらやっている。
会社にはいろんな社員ステータスがある。入社、退社、休職...
休職の場合、意図的に会社の情報に触れさせない必要もある。
雇用形態も様々。正社員、アルバイト、外部委託...
社員ステータスと雇用形態の組み合わせで権限を変える必要がある。
本人のモチベーションが下がるような情報を意図的に見せる必要はない。
GHEの導入。
社内の余剰サーバーにvbox headlessで利用。
さすがに辛くなったのでOpenStackでGHEを構築。
ベアメタルサーバー上で動作するため、物理サーバーに障害があると会社全部の仕事が止まってしまう。
GHEを円滑に動かせるようなOpenStack基盤を設計、構築。
GHEを円滑に動かすという経験が他のサービスの安定運用に繋がっている。
OpenStack上でGHEを動かすと手順書通りだと動かない。
メモリリソースも通常のサーバーで動かすより多く必要。
ディスクのマウントもデバッグしながら確認。
OpenStackは毎年リリースされて次の年にEOLになる。
ストレージアプライアンスを導入してGHEをいい感じで使えるようにした。
OpenStack Mitakaの運用状況。
2012年までは現状の使い方であればなんとかなるリソース。
ストレージアプライアンスの運用は大変。
コストも高い。
Tier2として可用性を落としても安価なストレージが採用できないか検討中。
BCPとしてGHEが一番最初に復旧するべき対象。
OpenStackが死んでもバックアップからAWS/GCPに半日くらいで復旧できる。
開発チームが使うGHE
GitHub Flow。
Branch作成、PR、レビュー、mergeしてデプロイ、を毎日行っている。
CIはDrone CIを採用。
OpenStack上に構築。Workerが20インスタンスくらい。
全サービス、全エンジニアが自由に使える。
Capistranoと連携。
GHEからテストしたコードをサーバ上にデプロイ。
プラグインを開発し、git tagをいい感じに打つように。
誰が、どういう内容で、どういう差分があったのかを、とにかく記録。
不具合があった場合、ソースコードの差分を確認することで一目瞭然。
tagでひたすら記録しておくことで、サービスのリリース頻度をを計測可能になる。
リリースの増減を認識できる。
エンジニア評価にもGHEを利用。
自分の評価資料をPull Requestで作成。だいたい半年かけて作成する。
全員が閲覧可能なのでハートをつけたりもできる。
他の人の考えや評価の主張をみんなが確認できる。
評価者と被評価者がディスカッションを通じて評価を作り上げる、というプロセスに重きを置いている。
他の同僚の評価資料とも簡単にコラボできる。
企画進行にも活用。
Issueで完結。
チェックボックスを使うことでタスクを洗い出し、仕事を可視化。
毎日100以上のPRが社内で作られている。Issueも200弱。コメントが1ヶ月で35000。
GitHub Enterpriseでこういう数字が出来る。
計測できないことは改善できない。
出すべきなのはスピード感ではなくてスピード。
変化に着目することを重視。
GHEのAPIを活用して、計測するためのツールをたくさん開発している。
全社員でのGHEの活用。
非エンジニアもGHEを全員使っている。
日本語が使えないサービスを見ると閉じてしまう社員もいる。
ファイル名に日本語を使ってしまう人もいる。
エンジニアにとっても難しいことがある。
OSSの運営管理をしている人はそんなに多くない。
権限やOrganizationの管理などは難しいことが多い。
情報システム部門の悩み。
2FAが分からない人もいて、設定解除などを都度問い合わせ対応。
入社/退職管理と名寄せ。
好きにアカウント名を作ってもらうと誰だかわからなくなる。
でも実名で作っちゃうとインターネットぽくない。
社内規定の管理。
GHEで管理。
全部Markdownで作成。
改定もPRを作成。
取締役会で決済されたらmerge。
G Suiteとの連携。
Google FormとGHEを連携。
Google Formで採用応募があったらGHEと連携してIssueを作成。
GHEで面接担当をアサイン。評価もIssueコメントで。
内容は相互で閲覧可能。
他者の面接コメントを見ることで面接スキルも向上。
テンプレートの活用。
Issueテンプレートによって、困ってることを共有。
仕事がうまくいかない原因は不安や不確実。
GHEの機能を使って排除してる。
開発以外にもGHEを利用。
BBQの企画もGHEで。
やっていき(リーダーシップ)とのっていき(フォローアップ)をGHEで実現。
自分の作業もGHEのコメントでひたすら書き続けて可視化、共有。
同僚への感謝もGHEで作成。メンションで相手に伝える。
GHEがコラボレーションスペースとして活用されている。
コラボレーションによって仕事は楽しくなる。楽しいには価値がある。
毎日楽しくなるようにGHEの使い方やソフトウェア開発を考えている。
さいごに
GitHubを使った評価制度は非常に面白いと思いました。僕自身も部長という立場なので、是非弊社でもやってみたいです。
